Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break up and simplify TransportFieldCapabilitiesAction #76958

Merged
merged 10 commits into from
Aug 30, 2021

Conversation

jtibshirani
Copy link
Contributor

@jtibshirani jtibshirani commented Aug 26, 2021

TransportFieldCapabilitiesAction currently holds a lot of logic. This PR
breaks it up into smaller pieces and simplifies its large doExecute method.
Simplifying the class will help before we start to make field caps
optimizations like #74648.

Changes:

  • Factor some methods out of doExecute to reduce its length
  • Pull AsyncShardAction out into its own class to simplify and better match
    the code structure in 7.x

@jtibshirani jtibshirani added :Search/Search Search-related issues that do not fall into other categories >refactoring v7.16.0 v8.0.0 labels Aug 26, 2021
@elasticmachine elasticmachine added the Team:Search Meta label for search team label Aug 26, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure yet exactly where things are heading with this, but I tried to keep an open mind :)

I've left some minor comments as I feel the PR is perhaps refactoring things a bit too much (just for the sake of adapting code style, perhaps less relevant for the future planned changes).

});
}
private ShardTransportHandler(IndicesService indicesService) {
this.fetcher = new FieldCapabilitiesFetcher(indicesService);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why this extra abstraction is needed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be very helpful when we add a new per-node execution strategy in #74648. We'll use this same logic as part of the new handler, but also need to maintain this old handler for BWC with older nodes. I'll revert this and just include the commit in the PR for #74648 so it's clear why it's necessary.

@jtibshirani
Copy link
Contributor Author

Thanks for the feedback @ywelsch, I try to have refactor PRs make sense on their own but this one ventured into "please read my mind about a future change" :)

@jtibshirani
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/part-2

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jtibshirani jtibshirani merged commit 061253e into elastic:master Aug 30, 2021
@jtibshirani jtibshirani deleted the field-caps-refactor branch August 30, 2021 17:14
jtibshirani added a commit to jtibshirani/elasticsearch that referenced this pull request Aug 30, 2021
`TransportFieldCapabilitiesAction` currently holds a lot of logic. This PR
breaks it up into smaller pieces and simplifies its large `doExecute` method.
Simplifying the class will help before we start to make field caps
optimizations.

Changes:
* Factor some methods out of `doExecute` to reduce its length
* Streamline index block checking

This backport doesn't include the change "Pull AsyncShardAction out into its
own class", since it's already part of a separate class in 7.x.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>refactoring :Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team v7.16.0 v8.0.0-alpha2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants